Waiting for the patches to be posted upstream

Waiting for the patches to be posted upstream

-updated upstream status to submitted

Please fix commit subject for the flatbuffers patch

DONE

Okay. Upstream (meta-oe) uses flatbuffers 25.12.19. To prevent possible issues with other packages which might depend on that version, we need to provide a separate version of the recipe (flatbuffers-tflite.bb, require recipes-devtools/flatbuffers/flatbuffers.bb) and use it for building TFLite.

Okay. Upstream (meta-oe) uses flatbuffers 25.12.19. To prevent possible issues with other packages which might depend on that version, we need to provide a separate version of the recipe (flatbuffers-tflite.bb, require recipes-devtools/flatbuffers/flatbuffers.bb) and use it for building TFLite.

--done

This doesn't build in my test system:

| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_configure
| CMake Error at CMakeLists.txt:23 (project):
|   VERSION ".." format invalid.
|
|
| -- Configuring incomplete, errors occurred!
| WARNING: exit code 1 from a shell command.
ERROR: Task (/home/lumag/Projects/RPB/build-rpb/conf/../../layers/meta-qcom-distro/recipes-ml/tflite/tensorflow-lite_2.20.0.qcom.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5751 tasks of which 5578 didn't need to be rerun and 1 failed.

Please explain why this flatbuffer recipe is needed, why the one from meta-oe is not enough, differences, etc, as part of your git commit message.

Please explain why this flatbuffer recipe is needed, why the one from meta-oe is not enough, differences, etc, as part of your git commit message.

If we are using flatbuffers version from meta-oe then we are facing below config issue as :

| /local/mnt/workspace/tushar/kas-tflite-build/build/tmp/work/armv8-2a-qcom-linux/tensorflow-lite/2.20.0.qcom/sources/tensorflow-lite-2.20.0.qcom/tensorflow/compiler/mlir/lite/schema/schema_generated.h:25:41: error: static assertion failed: Non-compatible flatbuffers version included
| 25 | static_assert(FLATBUFFERS_VERSION_MAJOR == 24 &&
| | ^
| /local/mnt/workspace/tushar/kas-tflite-build/build/tmp/work/armv8-2a-qcom-linux/tensorflow-lite/2.20.0.qcom/sources/tensorflow-lite-2.20.0.qcom/tensorflow/compiler/mlir/lite/schema/schema_generated.h:25:41: note: the comparison reduces to '(25 == 24)'
| ninja: build stopped: subcommand failed.
|
| WARNING: /local/mnt/workspace/tushar/kas-tflite-build/build/tmp/work/armv8-2a-qcom-linux/tensorflow-lite/2.20.0.qcom/temp/run.do_compile.3752035:153 exit 1 from 'eval ${DESTDIR:+DESTDIR=${DESTDIR} }VERBOSE=1 cmake --build '/local/mnt/workspace/tushar/kas-tflite-build/build/tmp/work/armv8-2a-qcom-linux/tensorflow-lite/2.20.0.qcom/build' "$@" -- ${EXTRA_OECMAKE_BUILD}'

I apologize for raising more suggestions, but I promise this is the last one from me.

No worries — thanks for all the suggestions. I’ve addressed all.

I apologize for raising more suggestions, but I promise this is the last one from me.

No worries — thanks for all the suggestions. I’ve addressed all.

Thanks

Trying to build yesterdays version of this PR for RB1 results in this:

| NOTE: DESTDIR=/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/image VERBOSE=1 cmake --install /build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build
| -- Install configuration: ""
| CMake Error at cmake_install.cmake:57 (file):
|   file INSTALL cannot find
|   "/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build/libtensorflowlite_c.so.2.20.0":
|   No such file or directory.

Checking the build folder, only the static library is present.

Trying to build yesterdays version of this PR for RB1 results in this:

| NOTE: DESTDIR=/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/image VERBOSE=1 cmake --install /build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build
| -- Install configuration: ""
| CMake Error at cmake_install.cmake:57 (file):
|   file INSTALL cannot find
|   "/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build/libtensorflowlite_c.so.2.20.0":
|   No such file or directory.

Checking the build folder, only the static library is present.

can you check now ?

Hi @lumag,
We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts.
TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues.
To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Trying to build yesterdays version of this PR for RB1 results in this:

| NOTE: DESTDIR=/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/image VERBOSE=1 cmake --install /build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build
| -- Install configuration: ""
| CMake Error at cmake_install.cmake:57 (file):
|   file INSTALL cannot find
|   "/build/tmp/work/cortexa53-qcom-linux/tensorflow-lite/2.20.0/build/libtensorflowlite_c.so.2.20.0":
|   No such file or directory.

Checking the build folder, only the static library is present.

can you check now ?

It works now, thanks!

Hi @lumag, We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts. TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues. To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Each AI framework and CamX currently rely on different versions of protobuf, leading to inconsistencies across the stack. Attempts to align the protobuf versions for LiteRT and TFLite resulted in functional regressions, indicating that modifying individual AI frameworks to support alternative versions is not a sustainable solution. A similar issue exists with FlatBuffer, where version mismatches create comparable challenges.
To address this, a unified and scalable approach is required for all use cases, including CamX, LiteRT, TFLite, LlamaCPP, ONNX Runtime, and ExecuTorch.
The solution that currently works reliably is the introduction of the protobuf-litert.bb recipe, which generates a dedicated protoc-litert binary. This binary is then explicitly provided to LiteRT for its build process. The same model should be adopted for other dependencies and AI frameworks to ensure consistent behavior and avoid cross‑framework version conflicts.

Hi @lumag, We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts. TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues. To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Each AI framework and CamX currently rely on different versions of protobuf, leading to inconsistencies across the stack. Attempts to align the protobuf versions for LiteRT and TFLite resulted in functional regressions, indicating that modifying individual AI frameworks to support alternative versions is not a sustainable solution. A similar issue exists with FlatBuffer, where version mismatches create comparable challenges. To address this, a unified and scalable approach is required for all use cases, including CamX, LiteRT, TFLite, LlamaCPP, ONNX Runtime, and ExecuTorch. The solution that currently works reliably is the introduction of the protobuf-litert.bb recipe, which generates a dedicated protoc-litert binary. This binary is then explicitly provided to LiteRT for its build process. The same model should be adopted for other dependencies and AI frameworks to ensure consistent behavior and avoid cross‑framework version conflicts.

Having a fork of the protobuf library for each component is still not scalable and makes maintaining such a solution cumbersome. The best approach would be to use static linking each component

Hi @lumag, We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts. TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues. To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Each AI framework and CamX currently rely on different versions of protobuf, leading to inconsistencies across the stack. Attempts to align the protobuf versions for LiteRT and TFLite resulted in functional regressions, indicating that modifying individual AI frameworks to support alternative versions is not a sustainable solution. A similar issue exists with FlatBuffer, where version mismatches create comparable challenges. To address this, a unified and scalable approach is required for all use cases, including CamX, LiteRT, TFLite, LlamaCPP, ONNX Runtime, and ExecuTorch. The solution that currently works reliably is the introduction of the protobuf-litert.bb recipe, which generates a dedicated protoc-litert binary. This binary is then explicitly provided to LiteRT for its build process. The same model should be adopted for other dependencies and AI frameworks to ensure consistent behavior and avoid cross‑framework version conflicts.

Having a fork of the protobuf library for each component is still not scalable and makes maintaining such a solution cumbersome. The best approach would be to use static linking each component

CamX is provided directly by Qualcomm, so its dependency alignment is generally not a concern. However, all other AI frameworks in the stack originate from external sources, which introduces additional constraints and makes version harmonization more challenging.

Hi @lumag, We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts. TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues. To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Each AI framework and CamX currently rely on different versions of protobuf, leading to inconsistencies across the stack. Attempts to align the protobuf versions for LiteRT and TFLite resulted in functional regressions, indicating that modifying individual AI frameworks to support alternative versions is not a sustainable solution. A similar issue exists with FlatBuffer, where version mismatches create comparable challenges. To address this, a unified and scalable approach is required for all use cases, including CamX, LiteRT, TFLite, LlamaCPP, ONNX Runtime, and ExecuTorch. The solution that currently works reliably is the introduction of the protobuf-litert.bb recipe, which generates a dedicated protoc-litert binary. This binary is then explicitly provided to LiteRT for its build process. The same model should be adopted for other dependencies and AI frameworks to ensure consistent behavior and avoid cross‑framework version conflicts.

Having a fork of the protobuf library for each component is still not scalable and makes maintaining such a solution cumbersome. The best approach would be to use static linking each component

CamX is provided directly by Qualcomm, so its dependency alignment is generally not a concern. However, all other AI frameworks in the stack originate from external sources, which introduces additional constraints and makes version harmonization more challenging.

In my opinion the ones provided in binary form by Qualcomm are the problematic ones because they will be constantly colliding with the open versions as soon as these are updated.
All other open-source frameworks compiled in the layer will use the same libraries version. It may be challenging, but they will have to share the same library version available upstream.

Hi @lumag, We noticed that protobuf-camx is being used by le-camera-service, and since both TFLite and le-camera-service will become dependencies for QIMSDK, we are concerned that integration with the camera stack may introduce conflicts. TFLite builds fine independently, but when combined with the camera service, using different protobuf variants could potentially cause issues. To avoid this, can we also switch TFLite to use protobuf-camx instead of the upstream protobuf?

Each AI framework and CamX currently rely on different versions of protobuf, leading to inconsistencies across the stack. Attempts to align the protobuf versions for LiteRT and TFLite resulted in functional regressions, indicating that modifying individual AI frameworks to support alternative versions is not a sustainable solution. A similar issue exists with FlatBuffer, where version mismatches create comparable challenges. To address this, a unified and scalable approach is required for all use cases, including CamX, LiteRT, TFLite, LlamaCPP, ONNX Runtime, and ExecuTorch. The solution that currently works reliably is the introduction of the protobuf-litert.bb recipe, which generates a dedicated protoc-litert binary. This binary is then explicitly provided to LiteRT for its build process. The same model should be adopted for other dependencies and AI frameworks to ensure consistent behavior and avoid cross‑framework version conflicts.

Having a fork of the protobuf library for each component is still not scalable and makes maintaining such a solution cumbersome. The best approach would be to use static linking each component

CamX is provided directly by Qualcomm, so its dependency alignment is generally not a concern. However, all other AI frameworks in the stack originate from external sources, which introduces additional constraints and makes version harmonization more challenging.

In my opinion the ones provided in binary form by Qualcomm are the problematic ones because they will be constantly colliding with the open versions as soon as these are updated. All other open-source frameworks compiled in the layer will use the same libraries version. It may be challenging, but they will have to share the same library version available upstream.

The issue in this patch is that it introduces a separate FlatBuffers version exclusively for TFLite. This is required because TFLite is not compatible with the FlatBuffers version provided by the latest Yocto release. The same incompatibility exists for Protobuf and FlatBuffers in LiteRT and LlamaCPP, and other AI frameworks have not yet been evaluated.
Regarding CamX, its Protobuf definitions are part of the LE Camera Services codebase, which is fully under our control. Any incompatibilities there can be resolved quickly, and the introduction of a new Protobuf recipe is not driven by LE Camera Services. At present, the latest LE Camera Server code compiles successfully using the Protobuf version included in Yocto.